Re: Telnet attack on SGI
Casper Dik (casper@Holland.Sun.COM)
Mon, 6 Nov 1995 16:27:29 +0100
Same Hartman wrote:
> Douglas> I'm curious exactly to see exactly how the various
> Douglas> vendors that have this vulnerability choose to fix it in
> Douglas> the long term. In the short term, patching telnetd seems
> Douglas> to be the solution. But what if the dynamic linker gets
> Douglas> a new variable in the future, and the people responsible
> Douglas> for that don't let the people responsible for telnetd
> Douglas> know?
If you have a common prefix for your ld.so environment variables, one
check is all you need: don't pass variables starting with that
common prefix. Solaris 2.5 telnetd strips out all variables
starting with LD_. Similarly in SunOS 4/Solaris 2.x login/su and
sendmail (the latest version of sendmail strips all of the envrionment:
that's the preferred solution, but not acceptable for login/su/telnetd)
> Ideally, there should be a way to pass environment variables
>into login in some sort of sane way outside the environment and have
>login add them. I believe many sysv logins will allow you to specify
>environment variables on the command line. This might be worth
>experimenting with--perhaps we could convince the BSD folks to add
>this if it had useful security benefits.
It's quite easy to do so. Simply prepend something to all environment
variables you want to pass to login and have login remove the prefix.
E.g., telnetd modifies all variable to be "PASSENV_<name>=<value>"
and login strips "PASSENV_" from all environment that start with that
value (and will still refuse LD_* and IFS, etc.)
People using csh scripts as login shells should note that even $TERM
is dangerous. So don't use Csh scripts as login shells.
Casper